Iteration 9 — console gate (R766-P05 part 1)

Following the Iteration 8 latency/load-time analysis, this commit implements part 1 of the R766-P05 follow-up.

What changed — rpcConcurrencyLogger gates the per-op host-side console.log (the framework's consoleProcedureLogger.log) behind extensionMode !== Production:

if (ext.context.extensionMode !== vscode.ExtensionMode.Production) {
    consoleProcedureLogger.log(entry);
}

Why — the dispatch logger fires on every completed RPC. The console line is useful when debugging the extension (F5 / "Run Extension" → Development, and Test) but is dead weight (string formatting + host-console I/O) on a shipped, installed build where nobody watches that console. Gating it means dev builds keep zero-friction visibility and packaged builds never execute it. The concurrency telemetry gauge stays unconditional and records in every mode, production included.

Notes

• The mode is read per call: ext.context is always populated by the time an RPC fires (the webview is open ⇒ the extension has activated), and the comparison is O(1) — no module-load ordering risk, no measurable added cost.
• The framework's consoleProcedureLogger stays the neutral, opt-in sink; the gating decision lives entirely in the DocumentDB adapter, preserving the package/consumer boundary.
• Tests stub ext.context.extensionMode per case and add a Test-mode case (still logs) and a Production case (no console line, gauge still recorded).

Scope — this closes the console half of R766-P05. The heavier half — callWithAccumulatingTelemetry running the full callWithTelemetryAndErrorHandling wrapper per op (which stays on in production by design) — is part 2, sequenced as Iteration 10 (Option 1: split the cheap accumulate path from the heavy flush path, and migrate all callers). Not started yet.

Validation: jest (4/4) · eslint (clean) · type-check (no errors) · prettier (unchanged). No user-facing strings.

Full decision record: docs/ai-and-plans/PRs/766-webview-ext-package-redesign/webview-ext-review.md (Iteration 9 change protocol + Iteration 10 plan). Commit: 8a279cf3.

Iteration 10 — accumulating-telemetry per-call cost (R766-P05 part 2)

Second half of the R766-P05 follow-up. Iteration 9 gated the console line; this one removes the heavier per-op cost that ran in production.

Problem — callWithAccumulatingTelemetry batched the telemetry emit (20 calls / 30 s) but still ran the full callWithTelemetryAndErrorHandling wrapper — IActionContext allocation, error-handling wiring, performance.now(), three Object.entries copy loops, an await — on every call. On hot paths (per webview RPC, per keystroke) that per-call machinery is the cost that adds up.

Redesign (Option 1) — the per-call path now runs the populator synchronously against a plain TelemetrySample bag and folds values into in-memory batch totals: no IActionContext, no await, no callWithTelemetryAndErrorHandling. The Azure pipeline is entered exactly once, on flush, with the rolled-up event.

// before
callWithAccumulatingTelemetry('evt', (ctx) => {
  (ctx.telemetry as TelemetryWithDistributions).distributions.gauge = n;
  ctx.telemetry.measurements.hits = 1;
});

// after — plain bag, synchronous, void
callWithAccumulatingTelemetry('evt', (sample) => {
  sample.distributions.gauge = n; // first-class field, no cast
  sample.measurements.hits = 1;
});

API change — callback is now (sample: TelemetrySample) => void (was (ctx: IActionContext) => T | PromiseLike<T> returning Promise<T | undefined>). This also retires the TelemetryWithDistributions cast. Safe because every call site already void-ed the result and used a synchronous callback.

Preserved semantics

• Errors never accumulate: a populator throw discards the sample and is reported once through callWithTelemetryAndErrorHandling under the same callbackId (the only remaining heavy path, and rare).
• Auto-duration (auto_duration_ms), dist_*_min/max/sum/count rollups, batch/interval throttle, flushAccumulatingTelemetry, and "flushed event name == callbackId" all unchanged.
• Added a finite guard in accumulate so a stray NaN/Infinity can't poison a sum or min/max reduction.

Callers migrated — ClustersExtension, DocumentDBShellPty (×6 trackers), collectionViewRouter, rpcConcurrencyLogger, and the meterSilentCatch shorthand. meterSilentCatch callers (schema store, connection strings, playground, tree items, …) needed no change — the shorthand's signature is unchanged.

Tests — helper test rewritten for the synchronous sample-bag API; added a finite-guard case and a "per-call path never enters the telemetry pipeline, only flush does" case (the redesign's core guarantee). rpcConcurrencyLogger test now invokes the captured callback with a sample bag directly.

Skill check — reviewed telemetry-instrumentation; it documents callWithTelemetryAndErrorHandling / publicProcedureWithTelemetry but not callWithAccumulatingTelemetry's callback shape, so no skill edit was needed.

Validation: jest 2668/2668 · eslint 0 errors (2 pre-existing unrelated require-await warnings in DocumentDBShellPty.ts) · tsc --noEmit clean · npm run build · prettier. No user-facing strings.

Full decision record: docs/ai-and-plans/PRs/766-webview-ext-package-redesign/webview-ext-review.md (Iteration 10). Commit: 0df2f8b0. This closes R766-P05 (both parts).

Iteration 11 — accumulating-telemetry rename (R766-P06)

Naming follow-up to Iteration 10. After the accumulate/flush split, the callWith… name was actively misleading: the callWith… convention in @microsoft/vscode-azext-utils promises "run my work inside a managed scope that hands me a full IActionContext (telemetry + errorHandling + ui + valuesToMask) and auto-records duration/result/errors." The redesigned helper does none of that on the per-call path — it fills a plain sample bag, synchronously, and returns void. Behavior unchanged; rename + file move only.

Renames

• callWithAccumulatingTelemetry → accumulateTelemetry
• flushAccumulatingTelemetry → flushAccumulatedTelemetry
• AccumulatingTelemetryOptions → AccumulateTelemetryOptions
• unchanged: TelemetrySample, AUTO_DURATION_DISTRIBUTION_KEY, meterSilentCatch
• file src/utils/callWithAccumulatingTelemetry.ts → src/utils/accumulatingTelemetry.ts (+ .test.ts), via git mv (history preserved); all importers updated, including the meterSilentCatch-only consumers and both jest.mock('…') paths.

The teachable distinction — the verb now encodes whether your callback runs:

• accumulateTelemetry(id, (sample) => …) — does not run your work (records a data point).
• a future runWithAccumulatingTelemetry(id, (sample) => action) — genuinely runs your action, so a runWith… name is honest there.

Naming the parameter sample (not ctx) reinforces it at every call site: sample.measurements visibly lacks sample.ui / sample.errorHandling.

Telemetry skill — reviewed .github/skills/telemetry-instrumentation; it documents callWithTelemetryAndErrorHandling / publicProcedureWithTelemetry but does not mention the accumulating helper by any name, so no skill edit was needed.

Deliverable 2 deferred — the "wrap an action" variant (runWithAccumulatingTelemetry: runs the action, batches successes, emits failures immediately, rethrows) is not built here. It's specced and filed as #777 (enhancement, [telemetry] title) for pickup when richer hot-path telemetry is needed.

Validation: jest 2668/2668 · eslint 0 errors (4 pre-existing unrelated require-await warnings) · tsc --noEmit clean · npm run build · prettier. No user-facing strings.

Full record: docs/ai-and-plans/PRs/766-webview-ext-package-redesign/webview-ext-review.md (Iteration 11). Commit: 1ee371f2.

✅ Code Quality Checks

This comment is updated automatically on each push.

📦 Build Size Report

Download artifact · updated automatically on each push.